home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9804 / 000074_linux@arm.uk.linux.org _Sat Apr 18 09:03:09 1998.msg < prev    next >
Internet Message Format  |  1998-05-13  |  5KB
  1. Return-Path: <linux@arm.uk.linux.org>
  2. Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id JAA02042
  4.     for <willy@odie.barnet.ac.uk>; Sat, 18 Apr 1998 09:03:08 +0100
  5. Received: from caramon.armlinux.org (dialup1.cymru.net [163.164.160.65]) by snowcrash.cymru.net (8.8.7/8.7.1) with ESMTP id JAA16998; Sat, 18 Apr 1998 09:03:22 +0100
  6. Received: from raistlin.armlinux.org (raistlin [192.168.0.3]) by caramon.armlinux.org (8.7.4/8.7.3) with ESMTP id JAA23389; Sat, 18 Apr 1998 09:21:01 +0100
  7. From: Russell King - ARM Linux Admin <linux@arm.uk.linux.org>
  8. Received: (from linux@localhost) by raistlin.armlinux.org (8.7.4/8.7.3) id JAA00406; Sat, 18 Apr 1998 09:03:25 +0100
  9. Message-Id: <199804180803.JAA00406@raistlin.armlinux.org>
  10. Subject: ADFS format (was Re: fd0* device for ADFS shape discs under i386 Linux)
  11. To: alan@cymru.net (Alan Cox)
  12. Date: Sat, 18 Apr 1998 09:03:23 +0100 (BST)
  13. Cc: vincent@waw.com, willy@odie.barnet.ac.uk, linux-arm@vger.rutgers.edu
  14. In-Reply-To: <199804180012.BAA11015@snowcrash.cymru.net> from "Alan Cox" at Apr 18, 98 01:12:22 am
  15. X-Mailer: ELM [version 2.4 PL24]
  16. MIME-Version: 1.0
  17. Content-Type: text/plain; charset=US-ASCII
  18. Content-Transfer-Encoding: 7bit
  19. Status: RO
  20.  
  21. Alan Cox writes:
  22. > A lot of kludging is done using block numbers, which works fine until you
  23. > hit an FS where blocks get moved around. smbfs implements a inodes on a
  24. > fs that has only path names stable
  25.  
  26. Ok, I think what I'll do at this point is supply a brief overview of the
  27. structure of ADFS/filecore filesystem, such that everyone knows the
  28. structure of the filesystem we're talking about.
  29.  
  30. ----------------------------------------------------------------------------
  31.  
  32. Filecore, like DOS has two distinct structures, the directory and
  33. effectively a map indicating allocation on the disk.  Under both, the
  34. directory contains all information to do with a file, and the map tells
  35. you where to find it.  This is, however, where the two diverge.
  36.  
  37. Filecore directories
  38. --------------------
  39.  
  40. Under filecore, the directory contains:
  41.     * Name
  42.     * Load address        \ These days, they're combined into a
  43.     * Execution address    / filetype/datestamp.
  44.     * Length
  45.     * Attributes
  46.     * File ID number
  47.  
  48. Directory entries are alphanumerically sorted and can have no gaps 
  49. (ie, you delete a file, and all the other entries get shifted up one
  50. position.
  51.  
  52. The ID number is the `key' to finding where the file is stored.  The ID
  53. number on it's own does not indicate where the file is.  You need the
  54. map to locate the file.  ID numbers refer to disk objects (fragment id)
  55. and offsets within a disk object (sector offset).
  56.  
  57.  
  58. Disk objects
  59. ------------
  60.  
  61. A disk object is similar to a file, but has a minimum size.  Several
  62. files (normally with a directory) can be stored in a disk object, but they
  63. don't have to be.
  64.  
  65. The map
  66. -------
  67.  
  68. The map is basically a bitstream.  The map is partitioned into sector sized
  69. zones.  Each map bit, relative to the first map bit indicates a set of sectors.
  70. (this is defined in the boot sector, in the log2bpmb/log2_bits_per_map_bit).
  71. A map entry consists of:
  72.  
  73.     +-------------+-------------+---+
  74.     | fragment id | zero bits   | 1 |
  75.     +-------------+-------------+---+
  76.  
  77. The fragment ID not only defines which entries to find, but which zone to
  78. start searching the map.
  79.  
  80. The zero bits define the size of this fragment.
  81.  
  82. Free blocks are indicated by a linked list of these blocks.  In this case,
  83. the `fragment id' is the offset to the next free block in this zone, or zero
  84. if this is the last.
  85.  
  86. ----------------------------------------------------------------------------
  87.  
  88. This allows filecore to automatically defrag the disk on the fly, since
  89. it doesn't need to find the directory associated with the file - it just
  90. changes the map.
  91.  
  92. The reason that the Linux adfs isn't able to be writable is indeed the way
  93. that it allocates inode numbers.  Inode numbers are currently defined to
  94. be the directories fragment ID << 8 and the entry offset within that
  95. directory.
  96.  
  97. ----------------------------------------------------------------------------
  98.  
  99. There you have it...  Hope it's useful. ;)
  100.    _____
  101.   |_____| ------------------------------------------------- ---+---+-
  102.   |   |        Russell King       linux@arm.uk.linux.org      --- ---
  103.   | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  104.   | +-+-+                                                     --- -+-
  105.   /   |               THE developer of ARM Linux              |+| /|\
  106.  /  | | |                                                     ---  |
  107.     +-+-+ -------------------------------------------------  /\\\  |